Skip to content

Support client cert validation (spki, hash, san)#5868

Merged
rudrakhp merged 8 commits intoenvoyproxy:mainfrom
kinolaev:tls-validation-context
Jun 30, 2025
Merged

Support client cert validation (spki, hash, san)#5868
rudrakhp merged 8 commits intoenvoyproxy:mainfrom
kinolaev:tls-validation-context

Conversation

@kinolaev
Copy link
Contributor

@kinolaev kinolaev commented Apr 30, 2025

What type of PR is this?

api: add publicKeyPins, certificateHashes and subjectAltNames fields to ClientTrafficPolicy.spec.tls.clientValidation
feat(translator): translate these fields to tls validation context

What this PR does / why we need it:
This PR allows to validate a client certificate against a list of SKPI hashes, certificate hashes or SANs using ClientTrafficPolicy

Which issue(s) this PR fixes:

#5909

Release Notes: Yes

@kinolaev kinolaev requested a review from a team as a code owner April 30, 2025 10:12
@kinolaev kinolaev force-pushed the tls-validation-context branch from f9b7336 to 0407b7e Compare April 30, 2025 10:16
@arkodg
Copy link
Contributor

arkodg commented May 2, 2025

hey hoping to get to this one in 1.5 weeks post v1.4 release

@codecov
Copy link

codecov bot commented May 2, 2025

Codecov Report

Attention: Patch coverage is 96.38554% with 3 lines in your changes missing coverage. Please review.

Project coverage is 70.93%. Comparing base (2dc3bf3) to head (11b890f).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
internal/xds/translator/listener.go 93.02% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5868      +/-   ##
==========================================
+ Coverage   70.84%   70.93%   +0.09%     
==========================================
  Files         220      220              
  Lines       37188    37259      +71     
==========================================
+ Hits        26345    26429      +84     
+ Misses       9295     9286       -9     
+ Partials     1548     1544       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@kinolaev kinolaev force-pushed the tls-validation-context branch from 0407b7e to 2ebdd7e Compare May 2, 2025 16:19
@kinolaev
Copy link
Contributor Author

kinolaev commented May 2, 2025

Thanks @arkodg , sounds good! I fixed crds and will add some tests to make Codecov happy)

@kinolaev
Copy link
Contributor Author

kinolaev commented May 3, 2025

Hi @arkodg , sorry for bothering you, but I've added tests, could you please rerun the pipeline? I'd like to be sure that Codecov is happy)

Additionally I've created an issue #5909 with a design proposal for this PR.
I believe it fully complies with your contribution guide now)

@kinolaev kinolaev force-pushed the tls-validation-context branch from c8a342b to e03472a Compare May 3, 2025 15:04
@kinolaev
Copy link
Contributor Author

kinolaev commented May 3, 2025

gen-check test failed because of broken make generate in the main branch. I rebased my branch and ran make generate again, the test must succeed now.
I also added a release note.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we name it PublicKeyHashes?

PublicKeyPins may be better here though. I'm just speaking from the perspective of a non-native English reader.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've chosen the name PublicKeyPins because the format base64(sha256(public key from cert in DER)) comes from Public Key Pinning Extension for HTTP rfc7469 where they have Public-Key-Pins HTTP header. But let me know if you still want me to rename it to PublicKeyHashes, I won't argue)

Copy link
Member

@zhaohuabing zhaohuabing Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd go with PublicKeyHashes or SPKIHashes because:

  • It's easier to understand at a glance, without requiring background knowledge of Public Key Pinning Extension for HTTP rfc7469.
  • Even though we use the same format of Public-Key-Pins HTTP header here, the purpose is different.

cc @envoyproxy/gateway-maintainers please vote for

  1. PublicKeyHashes
  2. SPKIHashes
  3. PublicKeyPins

My vote is either 1 or 2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do like SPKIHashes, I've renamed the field. Ready to do it again if the vote suggest a different option)

Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Prefer to add yaml tests to the gateway API translator and xDS translator instead of individual go tests files.

Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not strictly necessary, but adding an e2e test for client cert validation would be helpful.

@kinolaev
Copy link
Contributor Author

kinolaev commented Jun 8, 2025

@zhaohuabing I've added testdata as you requested to:

  • internal/gatewayapi/testdata/clienttrafficpolicy-mtls-client-verification.in.yaml
  • internal/xds/translator/testdata/in/xds-ir/mutual-tls-san.yaml

Do I have to delete all or some of go tests from the files below?

  • internal/gatewayapi/clienttrafficpolicy_test.go
  • internal/gatewayapi/helpers_test.go
  • internal/xds/translator/listener_test.go

@kinolaev kinolaev force-pushed the tls-validation-context branch 2 times, most recently from ef542b9 to 9d79c92 Compare June 8, 2025 11:29
@zhaohuabing
Copy link
Member

@zhaohuabing I've added testdata as you requested to:

  • internal/gatewayapi/testdata/clienttrafficpolicy-mtls-client-verification.in.yaml
  • internal/xds/translator/testdata/in/xds-ir/mutual-tls-san.yaml

Do I have to delete all or some of go tests from the files below?

  • internal/gatewayapi/clienttrafficpolicy_test.go
  • internal/gatewayapi/helpers_test.go
  • internal/xds/translator/listener_test.go

I think we wouldn't need clienttrafficpolicy_test.go and listener_test.go, but it's fine to keep them.

@kinolaev kinolaev force-pushed the tls-validation-context branch 2 times, most recently from eaa17f3 to 0d87295 Compare June 13, 2025 11:06
@kinolaev
Copy link
Contributor Author

we wouldn't need clienttrafficpolicy_test.go and listener_test.go

Agree, these were duplicates of testdata, I've removed them.

Copy link
Member

@zhaohuabing zhaohuabing Jun 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: consider renaming it to OtherSANNameMatch orOtherSANMatch ?
All API types are in the same namespace, a more specific name would be better.

Copy link
Contributor Author

@kinolaev kinolaev Jun 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SAN type OtherName is defined in section 4.2.1.6 Subject Alternative Name of rfc5280. Envoy and cert-manager follow this definition. That is why I'd prefer to not rename the field.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, OtherNameMatch works for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I'm sorry, only now I understand that you asked to rename the type and not the field! I agree I should definitely add "SAN" to the type name, I'll do it shortly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to OtherSANMatch

@zhaohuabing
Copy link
Member

zhaohuabing commented Jun 24, 2025

LGTM.

@kinolaev Can you resolve the conflicts and fix the lint?

kinolaev added 5 commits June 29, 2025 14:26
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
kinolaev added 2 commits June 29, 2025 14:26
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
Signed-off-by: Sergei Nikolaev <kinolaev@gmail.com>
@kinolaev kinolaev force-pushed the tls-validation-context branch from 0d87295 to a01c7e6 Compare June 29, 2025 10:41
@kinolaev
Copy link
Contributor Author

Thank you @zhaohuabing, the conflicts are resolved and CI is green now)

zhaohuabing
zhaohuabing previously approved these changes Jun 30, 2025
Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks!

Signed-off-by: Rudrakh Panigrahi <rudrakh97@gmail.com>
@rudrakhp rudrakhp requested a review from zhaohuabing June 30, 2025 03:17
@rudrakhp rudrakhp enabled auto-merge (squash) June 30, 2025 03:18
@rudrakhp rudrakhp merged commit 1445be7 into envoyproxy:main Jun 30, 2025
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants